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Status of this Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


1. Abstract 


This document represents an initial list of requirements submitted to 
the ATM Forum’s Multiprotocol BOF for the operation of IP over ATM 
networks as determined by the IETF IP over ATM Working Group and 
other working groups. This RFC is issued for the benefit of community 
members. The information contained in this document is accurate as 
of the date of publication, but is subject to change. Subsequent 
RFCs will reflect such changes. 


The content of this memo was submitted by the IETF Liaison to the ATM 
Forum as contribution number 94-0954 in the ATM Forum’s documentation 
process on 14 September 1994. 


2. Notice 


This contribution has been prepared to assist the ATM Forum. This 
document is offered to the Forum as a basis for discussion between 
the ATM Forum Multiprotocol BOF and the IETF. The statements are 
subject to change in form and content after further study and 
discussion. Specifically, the IETF reserves reserves the right to 
add to, amend or modify the statements contained herein. 


3. Introduction 


The following is the charter statement from the Internet Engineering 
Task Force’s (IETF) IP over ATM Working Group (IPATM WG). It is 
being reproduced here for the benefit of those in the ATM Forum who 
may not be familiar with it: 


"The IP over ATM Working Group will focus on the issues involved in 


running internetworking protocols over Asynchronous Transfer Mode 
(ATM) networks. The final goal for the Working Group is to produce 
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standards for the TCP/IP protocol suite and recommendations which 
could be used by other internetworking protocol standards (e.g., ISO 
CLNP and IEEE 802.2 Bridging). 


The Working Group will initially develop experimental protocols for 
encapsulation, multicasting, addressing, address resolution, call set 
up, and network management to allow the operation of internetwork 
protocols over an ATM network. The Working Group may later submit 
these protocols for IETF standardization. 


The Working Group will not develop physical layer standards for ATM. 
These are well covered in other standards groups and do not need to 
be addressed in this Group. 


The Working Group will develop models of ATM internetworking 
architectures. This will be used to guide the development of 
specific IP over ATM protocols. 


The Working Group will also develop and maintain a list of technical 
unknowns that relate to internetworking over ATM. These will be used 
to direct future work of the Working Group or be submitted to other 
standards or research groups as appropriate. 


The Working Group will coordinate its work with other relevant 
standards bodies (e.g., ANSI T1S1.5) to insure that it does not 
duplicate their work and that its work meshes well with other 
activities in this area. The Working Group will select among ATM 
protocol options (e.g., selection of an adaptation layer) and make 
recommendations to the ATM standards bodies regarding the 
requirements for internetworking over ATM where the current ATM 
standards do not meet the needs of internetworking." 


Historically, a large number of IETF IPATM WG participants are 
employees of companies who are principal members of the ATM Forum. 
Requirements between the two organizations have been communicated 
informally by these participants. With the establishment of the ATM 
Forum’s Multiprotocol BOF activities, it has become prudent now to 
document IETF requirements in a more formal fashion. 


At the July 1994 meeting of the IETF in Toronto, Canada, a request 
was presented to the IP over ATM Working Group by the ATM Forum 
Liaison, Drew Perkins, for the working group to prepare a list of 
requirements as input to the ATM Forum’s Multiprotocol BOF 
activities. This document is a response to that request. 
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4. List of Requirements for Consideration 
4.1 Standardization & Logistics 


- Formal communications between the IETF and the ATM Forum 
should be made via IETF <> ATM Forum Liaison(s), specific 
written communications (such as this document), and/or 
presentations made at official IETF or ATM Forum meetings. 


- IETF standards define how the TCP/IP protocol suite is defined, 
deployed, and carried over specific network technologies, 
including ATM networks [1][2][8]. 


- Any formal communications that affect the IETF standards 
or processes must be made publicly available as the IETF is 
a public international standards body. Ideally, such 
communications should be written as Internet Drafts [1], the 
IETF’s equivalent to incoming contributions. 


- We invite and encourage ATM Forum members to participate in 
the IETF standards process. See [1], [2], and [8] for 
information on how to participate. 


4.2 IPv4 Encapsulation 


- RFC 1483 [3] and RFC 1577 [4] define how IP is encapsulated 
and carried over ATM networks. The IPATM WG requests that any 
ATM Forum Multiprotocol work support these standards as 
specified, and that any future changes to them be made via the 
IETF standards process. 


4.3 Routing 


RFC 1577 defines the default Logical IP Subnet (LIS) model. 


- The IETF Routing over Large Clouds Working Group is developing 
the Next Hop Resolution Protocol, which allows the incremental 
optimization of routing (and subnets) by routing datagrams 
over preferential ATM paths [9]. 


- The IETF IP over ATM Working Group will be working on the 
next generation IP over ATM standards after RFC 1577 moves 
from draft to proposed status. Requirements to the ATM 
Forum will be forthcoming. 


- ATM signaling should give an indication of connection 


over LAN or WAN and include feedback of time vs byte 
charging. 
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4.4 Security 


- ATM signaling should support a user information element 
that is used to convey security and authentication information 
between IP members and applications. The IETF IPATM WG would 
like to define the IP specific content of this IE. 


4.5 Broadcast and Multicast 


— The IPATM WG is currently discussing models of how best to map 
IP multicast facilities onto ATM facilities. While this work is 
preliminary, the IETF does support the ATM Forum’s currently 
planned multicasting enhancements, such as leaf-initiated joins 
and support of multiple multicast congestion management 
policies. A further list of requirements will be presented at a 
later time. 


4.6 Signaling and Addressing 


- The IPATM WG is currently producing a specification for using 
UNI 3.0 and 3.1 signaling to support RFCs 1483 and 1577. This 
specification will be published as an informational reference 
for UNI 3.0 signaling, and as a proposed standard for UNI 3.1 
signaling following UNI 3.1’s ratification and official 
publication. 


- IPv6 packets will include a Flow ID field intended to support 
service classes in some way. Until the semantics of this field 
are fully defined it is hard to say much, but presumably a soft 
mapping between this and the VC to be used is desirable. A 
further list of requirements will be presented at a later time. 


- IPv6 addresses will be 16 bytes and there will likely bea 
defined embedding of them inside 20-byte NSAP format. There will 
also likely be a mapping of US-GOSIP-like NSAPs into IPv6 
addresses (deleting the unuseful bytes), but that is still 
controversial in the IPv6 discussions. A further list of 
requirements will be presented at a later time. 


Laubach [Page 4] 


RFC 1754 IPATM WG ATM Forum Recommendations V1 January 1995 


4.7 Quality of Service, Performance, and Traffic Management 


- ATM should support extremely bursty applications with 
Significant elasticity in their bandwidth demands. 


- ATM should support elastic applications as defined in 
RFC-1633 [7] very efficiently. That means enable high 
bottleneck utilization while keeping delay reasonably bounded 
(i.e., doubling delay wouldn’t be terrible for elastic apps). 
This should not be at the expense of delay sensitive classes 
of service. 


- ATM should provide a a class of service which strives to 
cooperate with existing TCP congestion avoidance, thereby 
explicitly providing support not only for directly ATM-attached 
and -aware endstations, but also for endstations on LANs (or 
using LAN Emulation) that are using current TCP implementations 
and interconnected via ATM-attached bridges and routers. 


— Predictive QoS should be supported in addition to guaranteed QoS 
to support applications which are somewhat tolerant of delay 
variation and low levels of loss. 


- IP uses both point-to-point and point-to-multipoint (future) 
connections. To satisfy IP’s needs an ABR-like service 


would need to be applicable to both types of connections [6]. 


- No specification of minimum or maximum bandwidths by the ATM 
end-systems [6]. 


- As simple as possible [6]. 

- Full line-rate transmission over otherwise-idle links [6]. 

- When end-to-end delay through the network is less than 1 second, 
the cell loss for AAL5 frames over an ABR-like service should be 
on the order of 3 in 10**8 cells for 1500 byte frames, or 3 in 
10**9 cells for 18 Kbyte frames [6]. 

5. Security Considerations 
Security issues raised in this memo will be addressed by the IETF IP 


over ATM Working Group and presented in subsequent updates to this 
memo. 
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